Digital communication systems where information is transmitted in data packages between a header and trailer are generally known as packet networks. Packets sent over a packet network are defined by a set of rules called protocols. A packet or frame typically includes some type of data or information in between a header and a trailer. Computer networks, such as local area networks (LANs), can use different protocols to send and receive data. Switched-packet networks use individual packets or frames of data that are routed individually through a network from a source to a destination. Each packet is comprised of a number of layers of protocol headers and data, for one or more network protocols. Packets conforming to the network protocol must have elements that satisfy the defined data values at their respective offsets.
Protocols analyzers connect to the communications bus of a communication network, such as a packet network, and collect and store information relating to the data protocol units that are traveling on the bus. Typical types of information include the origin and type of packet, the number of bits in the packet or frame, a timestamp, the destination address of the packet, and other information. This information is useful for network engineers in determining equipment requirements, the source of network problems, and administration of a network.
Network analyzers, sometimes referred colloquially as network “sniffers,” are helpful for network operations to capture and inspect packets as they travel through a particular location on the network. Packet inspections are performed in order to determine the quantities, distributions, and other parameters and protocols for packets. Analyzers capture and decode packets traveling between network hardware components. Packet details can be viewed to help isolate network problems and provide information on network traffic flow and monitoring. Some examples of network monitoring include traffic congestion, runaway traffic, traffic from each station or server, percent of bandwidth for a particular protocol, and isolation of traffic patterns. Protocol analyzers can capture packets in real time for immediate evaluation or save packets for a buffered analysis time, such as a first-in first-out buffer.
A network protocol defines the structure of valid packets formed according to the protocol. A protocol will define precisely the contents of a packet typically using a number of fields. Each field has a known offset from either the start of the packet or from the start of a predefined header. Offsets may be in bytes, bits, octets, or other units. For example, the specific order of the fields is defined, each field being followed by a specifically defined set of possible fields, each field have a specifically defined value or set of possible values.
Conventional network analyzers use microprocessors programmed by software to collect and store the packet information. However, systems cannot keep pace with high-speed network and data systems, therefore many systems resort to sampling data streams instead of analyzing each element of data. Some network analyzers use pattern matching to compare stored data for network protocols defining an FTP packet including an Internet Protocol (“IP”) address with the captured data from the network. Patterns of matching criteria are applied to a captured packet wherein the packet is scanned a number of times, equaling the number of matching criteria patterns. This process is resource intensive and typically cannot track every packet in network traffic. The protocol analyzers in the prior art are based on comparing packet information with some type of lookup table or protocol database where the rules for packets are pre-defined for protocols or network management statistics, for example comparing whether a data element is a “match” to a particular network protocol.
FIG. 1 illustrates a schematic of a conventional network analyzer 10 connected to packet network 12. For illustrative purposes, a network equipment or device (E1) 14 is connected at one end on packet network 12 and a network equipment or device (E2) 16 is connected at another end of packet network 12. E1 and E2 may also be two software applications or systems connected to a shared communication mechanism 12. E1 and E2 are in communication with each other using certain protocols in the exchange of messages. Network analyzer 10 captures some or all of the messages contained in packets that are transferred between E1 14 and E2 16. When a system problem occurs with one of the hardware devices, either or both equipment pieces may be removed from the network 12 and sent to a laboratory by a technician for evaluation to determine where the fault is occurring. However, error messages or error detections that occur in the field (e.g., while operating on network 12) will often not reproduce themselves and thus create difficulty in trouble-shooting the problems. Errors could be any or all of a sequence of messages, timing of messages, and content of messages between E1 14 and E2 16 that are being tested in a lab.
Typically, only one network device, for example E2, is removed from a network for error analysis. However, even if E1 and E2 are brought into a laboratory operating on the same software, message transmissions between them will not replay exactly the same with the same order and timing, and the error analysis of the message exchanges will fail. This is because test network equipment in the laboratory have different network configurations and timings than network 12 in the field. Some content of protocol messages between devices on a network is based on the local configuration. Individual timing of messages may be critical in determining protocol errors. To analyze the problem in the lab, messages have to be replayed from a network device E2 16, or software within the device, at a specific time and using local network parameters and protocols.
Therefore, if protocol messages transmitted between hardware equipment E1 and E2 do not precisely reproduce the original network messages and timing of messages in a laboratory setting, and also using the local network parameters, there are problems reproducing error conditions and errors themselves that were detected on network 12.
Similar problems occur when diagnosing errors between two software programs operating on the same computer. For software diagnostics, E1 and E2 are different software programs, or different software modules, in the same computer, and connection 12 is an interprocess communication connection. Message transmissions between E1 and E2 will not replay exactly the same with the same order of timing as when the error first occurred, and the analysis of message exchanges to determine the exchange where an error is occurring will fail in a laboratory replay. This is because laboratory-tested network software may be located on a different computer in a lab or different setup configurations than the software programs in the field computer. At the least, the software programs are replayed at a later time in the laboratory, so that the real time message transmissions are not exactly replayed. Much of the content of protocol messages between software programs on a computer are exchange-specific, and timing of the messages are an important part of most protocols. Therefore, a message may be replayed using software program E2 16 and software program E1 14 at a different time using different setup parameters and protocols which may not repeat the same errors.